Application hosting is a growing trend in the provision of Internet applications. Host farms co-locate large numbers of servers and other application hosting components, hereinafter referred to collectively as application components, at geographically advantageous locations to provide application hosting services having efficient access to an Internet hub. The centralization of application components also provides for efficiencies in the operations of the application components, since the application components associated with different hosted applications can be managed through a single set of support, administration, and management systems and tools (hereinafter referred to collectively as “back-end systems”).
The back-end systems of application hosting systems maybe built around a back-end network, which may be separate from front-end interfaces used to communicate hosted web applications to web-site visitors. A back-end network provides a communications path between the back-end systems and the application components, however the back-end network is limited to passively transmitting information from a sender to a receiver. Typically, each message sent over the back end network contains a network address to identify a recipient of the message, and data comprising the body of the message. The destination of each message is determined by the sender of the message. In order to allow a recipient of a message to understand the data contained within the message, the message must be formatted according to a protocol known to both the sending and receiving components. Additionally, the sending component must have knowledge of the existence of the intended recipient component and the necessity to send the message to the component. Accordingly, such a communications protocol is feasible where two components are required to be able to communicate, but becomes more difficult as additional components are added.
Providing a known format to both the sending and receiving components may be resolved by the use of application program interfaces, which act as translators between the components. Alternately, components may use a widely known format for transmitting the data, such that a tool may be originally written to communicate over the back-end network according to a known format. Message formats may also utilize published definitions, such that components may reference the published definitions to interpret the contents of the message. Such published definition sets can be implemented directly on the component, such as the use of Internet browsers which contain information for interpreting HTML (hypertext markup language). Hybrids may also be utilized, wherein a portion of a format definition may be distributed to each component, while format definitions for specific message types may be stored at a third location, such that components can access the definitions for specific messages, and also be informed of the necessity of sending the message in the first place by reference to the material contained at the third location.
Tools which comprise the back-end system may differ from function to function. One vendor may make a particularly effective tool for monitoring the performance of a hosted application, while a different vendor provides an effective tool for tracking service requests. The use of varied tools to handle varying back-end functions limits the ability to automate responses which are dependant upon information being sent from a sending computer to an address, unless the sending component is originally programmed with instructions identifying destinations for each message.
The ability to provide this functionality to each computer in an application hosting system is severely constrained. The destination of each message sent from a computer may be dependant on both internal and external considerations. Internal considerations may include the contents of the message, and the identity of the computer sending the message. External considerations could include identifying a responsible party for responding to a specific message from a sending computer. Accordingly, when a message is sent by a component, the identification and resolution of any events or conditions described in the message presently requires the involvement of human operators before indicated responses can be taken. The involvement of human operators delays the resolution of any situation indicated by the message, and thus may adversely affect the performance of the component which initiated the message.
An example of such a situation would be the transmission of a fault message related to application software. Such a message may be transmitted to a hosted application customer associated with the application software. Once the message is received by the customer, the customer must be able to determine corrective actions, and who should be notified of the necessity of initiating the corrective actions. Such messages may be transmitted to the customer via posting at a portal into the management system, further delaying resolution until the customer accesses the portal.
Alternately, requests made by a customer to an application hosting system also require that determinations be made regarding how the request should be handled, and additionally what management functions need to be informed of the request and any proposed response. Thus, delays inherent in making such determinations delay resolution of the request, delaying any benefit to be achieved under the request.